We could add this to the configuration if we plan to change it dynamically. I opted to keep it here for now, but I'm open to externalizing the configuration.

As we have two instances and this is stored in memory, won't this mean the log is emitted twice each time?

I moved this to Redis in aea8544.

Thank you for looking into this Aaron! The memory storage was created to alleviate cache usage when receiving a lot of unsupported events in a short period. The log would indeed be emitted N times on each cycle (N being the number of running instances). Still, each instance would print the number of events received by the instance, and monitoring tools can aggregate the numbers if needed.

Sorry, this approach was highly opinionated and probably should have been discussed beforehand, I'm fine with using Redis for storing a unified counter, but I also think we should use an atomic counter (Redis INCR) instead of a plain hash (as implemented on aea8544) for both consistency (dirty writes) and performance. Wdyt @iamacook @PooyaRaki ?

(Btw, if we think this should be changed, I'd be super happy to tackle it on a separate PR so we can merge this one and unblock the feature 🙂 )

I don't think we need to implement OnModuleInit here.

I've just found out that onModuleInit lifecycle hook is called by NestJS if a class defines a method called onModuleInit, regardless of whether the class explicitly implements the OnModuleInit interface.

So even if the interface is not mandatory for the hook to work, I think it is a good practice to use it for clarity and to ensure your class conforms to the expected structure, so I've explicitly set both HooksRepositoryWithNotifications and HooksRepository as OnModuleInit implementations in 7d695ee